home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-03-05 | 53.4 KB | 1,205 lines |
- Linux Security HOWTO
- Kevin Fenzi, kevin@scrye.com
- v0.9.5, 1 March 1998
-
- This document is a general overview of security issues that face the
- administrator of linux systems. It covers general security philosophy
- and a number of specific examples of how to better secure your linux
- system from intruders. Also included are pointers to security related
- material and programs. NOTE: This is a beta version of this document.
- Improvements, constructive criticism, additions and corrections are
- gratefully excepted. Due to my despam filter, you will need to mail
- me to get a despam key to mail me. Sorry for the trouble. To avoid
- this make sure you have "linux", "security" or "HOWTO" in the subject
- line of your mail.
-
- 1. Introduction
-
- This document covers some of the main security issues that affect
- linux security. General philosophy and net born resources are
- discussed.
-
- A number of other HOWTO documents overlap with security issues, and
- those have been pointed to wherever appropriate.
-
- This document is NOT meant to be a up to date exploits document. Large
- numbers of new exploits happen all the time. This document will tell
- you where to look for such up to date information, and some general
- methods to prevent such exploits from taking place.
-
- 1.1. New versions of this document
-
- New versions of this document will be periodically posted to
- comp.os.linux.answers. They will also be added to the various
- anonymous FTP sites who archive such information, including:
-
- ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
-
- In addition, you should generally be able to find this document on the
- Linux Worldwide Web home page via:
-
- http://sunsite.unc.edu/mdw/linux.html
-
- Finally, the very latest version of this document should also be
- available in various formats from:
-
- http://scrye.com/~kevin/lsh/
-
- 1.2. Feedback
-
- All comments, error reports, additional information and criticism of
- all sorts should be directed to:
-
- kevin@scrye.com
-
- NOTE: I use the despam filter to filter all my mail. This means that
- if you are not known to me, your mail will bounce with a notice to re-
- send with a provided "key" in the subject. I regret the trouble this
- causes, but since I get 20-30 spam mails a day, I have to do
- something. Please re-send your message with the "key" in the subject
- and I will read your mail. You can also avoid this step by making sure
- you put "linux" "security" or "HOWTO" in the subject of your mail.
- http://scrye.com/~kevin/
-
- 1.3. Disclaimer
-
- No liability for the contents of this documents can be accepted. Use
- the concepts, examples and other content at your own risk.
- Additionally, this is an early version, with many possibilities for
- inaccuracies and errors.
-
- A number of the examples and descriptions use the RedHat(tm) package
- layout and system setup. Your mileage may vary.
-
- As far as I know, only programs that under certain terms may be used
- or evaluated for personal purposes will be described. Most of the
- programs will be available complete with source under GNU-like terms.
-
- 1.4. Copyright information
-
- This document is copyrighted (c)1998 Kevin Fenzi and distributed under
- the following terms:
-
- ╖ Linux HOWTO documents may be reproduced and distributed in whole or
- in part, in any medium physical or electronic, as long as this
- copyright notice is retained on all copies. Commercial
- redistribution is allowed and encouraged; however, the author would
- like to be notified of any such distributions.
-
- ╖ All translations, derivative works, or aggregate works
- incorporating any Linux HOWTO documents must be covered under this
- copyright notice. That is, you may not produce a derivative work
- from a HOWTO and impose additional restrictions on its
- distribution. Exceptions to these rules may be granted under
- certain conditions; please contact the Linux HOWTO coordinator at
- the address given below.
-
- ╖ If you have questions, please contact Greg Hankins, the Linux HOWTO
- coordinator, at
-
- gregh@sunsite.unc.edu Finger for phone number and snail mail address.
-
- 2. Overview
-
- This document will attempt to explain some procedures and commonly
- used software to help your linux system be more secure.
-
- The first thing to keep in mind is that there is never any such thing
- as a "completely" secure computer system. All you can do is make it
- increasingly difficult for someone to compromise your system. For the
- average home linux user, not much is required to keep the causal
- cracker at bay. For high profile linux users (banks,
- telecommunications companies, etc) much more work is required.
-
- Another factor to take into account is that the more you increase your
- system security, the more intrusive your security becomes. You need to
- decide where in this balancing act your system is still usable and yet
- secure for your purposes. For instance, you could require everyone
- dialing into your system to use a call back modem to call them back at
- their home number. This is more secure, but if someone is not at home,
- it makes it difficult for them to login. You could also setup your
- linux system with no network or connection to the Internet, but this
- makes it harder to surf the web. If you are a large to medium sized
- site, you should establish a "Security Policy" stating how much
- security is required by your site and what auditing is in place to
- check it.
-
- This document has been segregated into several sections. They cover
- several broad kinds of security issues. The first, physical security,
- covers how you need to protect your physical machine from tampering.
- The second describes how to protect your system from tampering by
- local users. The third, network security, describes how to better
- secure your linux system from network attacks. The next discusses what
- to do when you detect a system compromise in progress or detect one
- that has recently happened. Then links to other security resources are
- enumerated, and finally a few closing words.
-
- The two main points to realize when reading this document are:
-
- ╖ Be aware of your system. Check system logs such as
- /var/log/messages and keep an eye on your system, and
-
- ╖ Two, keep your system up to date by making sure you have installed
- the current versions of software and have upgraded per security
- alerts. Just doing this will help make your system markedly more
- secure.
-
- 3. Physical Security
-
- The first "layer" of security you need to take into account is the
- physical security of your computer systems. Who has direct physical
- access to your machine? Should they? Can you protect your machine from
- their tampering? Should you?
-
- How much physical security you need on your system is very dependent
- on your situation, and/or budget.
-
- If you are a home user, you probably don't need a lot (although you
- might need to protect your machine from tampering by children or
- annoying relatives). If you are in a Lab environment, you need
- considerably more, but users will still need to be able to get work
- done on the machines. Many of the following sections will help out. If
- you are in a Office, you may or may not need to secure your machine
- off hours or while you are away. At some companies, leaving your
- console unsecured is a termination offense.
-
- Obvious physical security methods such as locks on doors, cables,
- locked cabinets, and video survailance are all a good idea, but beyond
- the scope of this document. :)
-
- 3.1. Computer locks
-
- Many more modern pc cases include a "locking" feature. Usually this
- will be a socket on the front of the case that allows you to turn an
- included key to a locked or unlocked position. Case locks can help
- prevent someone from stealing your pc, or opening up the case and
- directly manipulating/stealing your hardware. They can also sometimes
- prevent someone from rebooting your computer on their own floppy or
- other hardware.
-
- These case locks do different things according to the support in the
- motherboard and how the case is constructed. On many pc's they make it
- so you have to break the case to get the case open. On some others
- they make it so that it will not let you plug in new keyboards and
- mice. Check your motherboard or case instructions for more
- information. This can sometimes be a very useful feature, even though
- the locks are usually very low quality and can easily be defeated by
- attackers with locksmithing.
-
- Some cases (most notably sparcs and macs) have a dongle on the back
- that if you put a cable through attackers would have to cut the cable
- or break the case to get into it. Just putting a padlock or combo lock
- through these can be a good deterrent to someone stealing your
- machine.
-
- 3.2. BIOS Security
-
- The BIOS is the lowest level of software that configures or
- manipulates your x86 based hardware. LILO and other linux boot methods
- access the BIOS to determine how to boot up your linux machine. Other
- hardware that linux runs on has similar software (OpenFirmware on macs
- and new suns, sun boot prom, etc...). You can use your BIOS to prevent
- attackers from rebooting your machine and manipulating your linux
- system.
-
- Under linux/x86 many pc bioses let you set a boot password. This
- doesn't provide all that much security (bios can be reset, or removed
- if someone can get into the case), but might be a good deterant (ie it
- will take time and leave traces of tampering).
-
- Many x86 bioses also allow you to specify various other good security
- settings. Check your bios manual or look at it the next time you boot
- up. Some examples are: disallow booting from floppy drives and
- passwords to access some bios features.
-
- On Linux/Sparc, your SPARC eeprom can be set to require a boot-up
- password. This might slow attackers down.
-
- NOTE: If you have a server machine, and you setup a boot password,
- your machine will not boot up unattended. Keep in mind that you will
- need to come in and supply the password in the even of a power
- failure. ;(
-
- 3.3. Boot loader Security
-
- The various linux boot loaders also can have a boot password set.
- Using lilo take a look at the "restricted" and "password" settings.
- "password" allows you to set a bootup password. "restricted" will let
- the machine boot _unless_ someone specifies options at the lilo:
- prompt (like 'single').
-
- Keep in mind when setting all these passwords that you need to
- remember them. :) Also remember that these passwords will mearly slow
- the determined attacker.
-
- If anyone has security related information from a different boot
- loader, I would love to hear it. (grub, silo, milo, linload, etc).
-
- NOTE: If you have a server machine, and you setup a boot password,
- your machine will not boot up unattended. Keep in mind that you will
- need to come in and supply the password in the even of a power
- failure. ;(
-
- 3.4. xlock and vlock
-
- If you wander away from your machine from time to time, it is nice to
- be able to "lock" your console so that no one tampers with or looks at
- your work. Two programs that do this are: xlock and vlock.
- Xlock is a X display locker. It should be included in any linux
- distributions that support X. Check out the man page for it for more
- options, but in general you can run xlock from any xterm on your
- console and it will lock the display and require your password to
- unlock.
-
- vlock is a simple little program that allows you to lock some or all
- of the virtual consoles on your linux box. You can lock just the one
- you are working in or all of them. If you just lock one, others can
- come in and use the console, they will just not be able to use your
- vty until you unlock it. vlock ships with redhat linux, but your
- mileage may vary.
-
- Of course locking your console will prevent someone from tampering
- with your work, but does not prevent them from rebooting your machine
- or otherwise disrupting your work.
-
- 3.5. Detecting Physical Security compromises.
-
- The first thing to always note is when your machine was rebooted.
- Since linux is a robust and stable OS, the only times your machine
- should reboot is when YOU take it down for OS upgrades, hardware
- swapping, or the like. If your machine has rebooted without you doing
- it, a trouble light should go on. Many of the ways that your machine
- can be compromised require the intruder to reboot or power off your
- machine.
-
- Check for signs of tampering on the case and computer area. Although
- many intruders clean traces of their presence out of logs, it's a good
- idea to check through them all and note any discrepancy.
-
- Some things to check for in your logs:
-
- ╖ Short or incomplete logs.
-
- ╖ Logs containing strange timestamps.
-
- ╖ Logs with incorrect permissions or ownership.
-
- ╖ Records of reboots or restarting of services.
-
- ╖ missing logs.
-
- ╖ su entries or logins from strange places.
-
- Where to look for your log file will depend on your distribution. In
- the standard redhat setup, you will want to look in /var/log/ and
- check messages, mail.log, and others.
-
- You might also want to configure your log-rotating script or daemon to
- keep logs around longer so you have time to examine them. Take a look
- at the 'logrotate' package un recent redhat distributions. Other
- distributions likely have a similar process.
-
- 4. Local Security
-
- The next thing to take a look at is the security in your system
- against attacks from local users. Did I just say _local_ users? yes.
-
- Getting access to a local user is one of the first things that system
- intruders attempt. With lax local security, they can then "upgrade"
- their normal user access to root access using a variety of bugs and
- poorly setup local services. If you make sure your local security is
- tight, then the intruder will have another hurdle to jump.
- Local users can also cause a lot of havoc with your system even
- (especially) if they really are who they say they are. Providing
- accounts to people you don't know or have no contact information for
- is a very bad idea.
-
- Before changing permissions on any system files, make sure you
- understand what you are doing. Never change permissions on a file
- because it seems like the easy way to get things working. Always
- determine why the file has that permission before changing it.
-
- 4.1. Creating new accounts
-
- You should make sure and provide user accounts with only the minimal
- requirements for the task. If you provide your son (age 10) with an
- account, you might want them to only have access to a word processor
- or drawing program, but be unable to rm everything.
-
- Several good rules of thumb when allowing other people legitimate
- access to your linux machine:
-
- ╖ Give them the minimal amount of privileges they need.
-
- ╖ Be aware when/where they login from, or should be logging in from.
-
- ╖ Make sure and remove their account when they no longer need the
- access.
-
- Many local user accounts that are used in security compromises are
- ones that have not been used in months or years. Since no one is using
- them they provide the ideal attack vehicle.
-
- 4.2. File Permissions
-
- It's important to insure that your system files are not open for
- casual editing by users and groups who shouldn't be doing such system
- maintance.
-
- A quick explanation of unix permissions:
-
- Ownership - Which user(s) and group(s) retain(s) control of the
- permission settings of the node and parent of the node
-
- Permissions - Bits capable of being set or reset to allow certain
- types of access to it.
-
- Read:
-
- ╖ To be able to view contents of a file
-
- ╖ To be able to read a directory
-
- Write:
-
- ╖ To be able to add to or change a file
-
- ╖ To be able to delete or move files in a directory
-
- Execute:
-
- ╖ To be able to run a binary program
-
- ╖ To be able to search in a directory
-
- You - The owner of the file
-
- Group - The group you belong to
-
- Everyone - Anyone on the system
-
- Examples:
- -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
- 1st bit - directory? (no)
- 2nd bit - read by owner? (yes, by kevin)
- 3rd bit - write by owner? (yes, by kevin)
- 4th bit - execute by owner? (no)
- 5th bit - read by group? (yes, by users)
- 6th bit - write by group? (no)
- 7th bit - execute by group? (no)
- 8th bit - read by everyone? (yes, by everyone)
- 9th bit - write by everyone? (no)
- 10th bit - execute by everyone? (no)
-
- drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
- 1st bit - directory? (yes, it contains many files)
- 2nd bit - read by owner? (yes, by kevin)
- 3rd bit - write by owner? (yes, by kevin)
- 4th bit - execute by owner? (yes, by kevin)
- 5th bit - read by group? (yes, by users
- 6th bit - write by group? (no)
- 7th bit - execute by group? (yes, by users)
- 8th bit - read by everyone? (yes, by everyone)
- 9th bit - write by everyone? (no)
- 10th bit - execute by everyone? (yes, by everyone)
-
- System configuration files (usually in /etc) are usually mode 644
- (-rw-r--r--), and owned by root. Depending on your sites security
- requirements, you might adjust this. Never leave any system files
- writable by a group or everyone.
-
- 4.3. Root security
-
- Another common local user attacker is the admin of your linux box.
- yes, you! ;) Remember that you should only use the root account for
- very short specific tasks and should mostly run as a normal user.
- Running as root all the time is a very very very bad idea. Just use
- su or sudo to do those tasks you need to do.
-
- Several tricks to avoid messing up your own box as root:
-
- ╖ When doing some complex command, try running it first in a non
- destructive way...especially commands that use globbing: ie, you
- are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak"
- and make sure you are going to delete the files you think you are.
- Using echo in place of destructive commands also sometimes works.
-
- ╖ Some people find it helpfull to do a "touch /-i" on their systems.
- This will make commands like: "rm -rf *" ask you if you really want
- to delete all the files. (It does this by your shell resolving the
- "-i" file first, and treating it as the -i option to rm.) This will
- not help with rm statements with no * in them. ;(
-
- ╖ Only become root to do single specific tasks. If you find yourself
- trying to figure out how to do something, go back to a normal user
- shell until you are sure what needs to be done by root.
-
- ╖ Always be slow and deliberate running as root. Your actions could
- affect a lot of things. Think before you type!
-
- If you absolutely positively need to allow someone (hopefully very
- trusted) to have superuser access to your machine, there are a few
- tools that can help. Sudo allows users to use their password to access
- a limited set of commands as root. This would allow you to, for
- instance, let a user be able to eject and mount removable media on
- your linux box, but have no other root privileges. sudo also keeps a
- log of all sudo attempts and successes, allowing you to track down who
- used what command to do what. For this reason sudo works well even in
- places where a number of people have root access, but use sudo so you
- can keep track of changes made.
-
- 4.4. Trojan Horses
-
- A Trojan Horse is named after the fabled ploy in Homers great literary
- work. The idea is that you put up a program or binary that sounds
- great, and get other people to download it and run it as root. Then,
- you can compromise their system while they are not paying attention.
- While they think the binary they just pulled down does one thing (and
- it might very well), it also compromises their security.
-
- You should take care of what programs you install on your machine.
- redhat provides md5 checksums and pgp signed rpm files so you can
- verify you are installing the real thing. Other distributions have
- similar methods. You should never run any binary you don't have the
- source for or a well known binary as root! Few attackers are willing
- to release source code to public scrutiny.
-
- Although it can be complex, make sure you are getting the source for
- some program from it's real distribution site. If the program is going
- to run as root make sure either you or someone you trust has looked
- over the source and verified it.
-
- 4.5. Password Security & Encryption
-
- One of the most important security features used today are passwords.
- It is important for both you and all your users to have secure,
- unguessable passwords. Most of the more recent linux distributions
- include 'passwd' programs that not allow you to set a easily guessable
- password. Make sure your passwd program is up to date and has these
- features.
-
- In depth discussion of encryption is beyond the scope of this document
- , but a introduction is in order. Encryption is very usefull, possibly
- even nessessary in this day and age. There are all sorts of methods of
- encrypting data, each with their own flaws and drabacks. Some of the
- more common ones you should be aware of:
-
- unix password encryption: Most unicies (and linux is no exception) use
- the DES (Data Encryption Standard) to encrypt your passwords. This
- encrypted password is then stored in (typically) /etc/passwd (or less
- commonly) /etc/shadow. When you attempt to login, whatever you type in
- is encrypted again and compaired with the entry in the passwd file. If
- they match, it must be the same password and you are allowed access.
- DES is a one-way encryption. DES is know to be pretty weak in these
- days of fast computers. Brute force attacks, such as crack or John the
- ripper (see below) can often guess passwords unless your password is
- sufficently random. PAM modules (see below) allow you to use a
- diffrent encryption routine with your passwords (MD5 or the like).
-
- 4.5.1. PAM - Pluggable Authentication Modules
-
- Newer versions of the RedHat linux distribution ship with a thing
- called "PAM". PAM allows you to change on the fly your authentication
- methods and requirements. Without re-compiling any of your binaries.
- Configuration of PAM is beyond the scope of this document, take a look
- at the PAM web site for more information.
- http://www.kernel.org/pub/linux/libs/pam/index.html
-
- Just a few of the things you can do with PAM:
-
- ╖ Use a non DES encryption for your passwords. (Making them harder to
- brute force decode.
-
- ╖ Set resource limits on all your users so they can't perform denial
- of service attacks (number of processes, amount of memory, etc).
-
- ╖ Enable shadow passwords (see below) on the fly.
-
- ╖ allow specific users to login only at specific times from specific
- places.
-
- 4.5.2. Shadow Passwords.
-
- Shadow passwords are a means of keeping your encrypted password
- information secret from normal users. Normally this encrypted password
- is stored in your /etc/passwd file for all to read. They can then run
- password guesser programs on it and attempt to determine what it is.
- Shadow passwords save this information to a /etc/shadow file that only
- privileged users can read. In order to run shadow passwords you need
- to make sure all your utilities that need access to password
- information are recompiled to support it. PAM (above) also allows you
- to just plug in a shadow module and doesn't require re-compilation of
- executables.
-
- 4.5.3. Crack and John the Ripper
-
- If for some reason your passwd program is not enforcing non easily
- guessable passwords, you might want to run a password cracking program
- and make sure your users passwords are secure.
-
- Password cracking programs work on a simple idea. They try every word
- in the dictionary, and then variations on those words. They encrypt
- each one and check it against your encrypted password. If they get a
- match they are in.
-
- There are a number of programs out there...the two most notable of
- which are "Crack" and "John the Ripper"
- http://www.false.com/security/john/index.html . They will take up a
- lot of your cpu time, but you should be able to tell if an attacker
- could get in using them by running them first yourself and notifying
- users with weak passwords. Note that an attacker would have to use
- some other hole first in order to get your passwd (unix /etc/passwd)
- file, but these are more common than you might think.
-
- 4.6. Integrity Checking with Tripwire
-
- Another very good way to detect local (and also network) attacks on
- your system is to run an integrity checker like Tripwire. Tripwire
- runs a number of checksums on all your important binaries and config
- files and compares them against a database of former values. Thus, any
- changes in the files will be flagged.
-
- It's a good idea to install tripwire onto a floppy, and then
- physically set the write protect on the floppy. This way intruders
- can't tamper with tripwire itself or change the database. Once you
- have tripwire setup, it's a good idea to run it once a day or so and
- check to see if anything has changed.
-
- You can even add a crontab entry to run tripwire from your floppy
- every night and mail you the results in the morning. Something like:
-
- # set mailto
- MAILTO=kevin
- # run tripwire
- 15 05 * * * root /usr/local/adm/tcheck/tripwire
-
- will mail you a report each morning at 5:15am.
-
- Tripwire can be a godsend to detecting intruders before you would
- otherwise notice them. Since a lot of files change on the average
- system, you have to be careful what is cracker activity and what is
- your own doing.
-
- 4.7. CFS - Cryptographic File System and TCFS - transparent crypto¡
- graphic File System.
-
- CFS is a way of encrypting an entire file system and allow users to
- store encrypted files on them. It uses a NFS server running on the
- local machine. rpms are avail at http://www.replay.com/redhat/ and
- more information on how it all works is at:
- ftp://ftp.research.att.com/dist/mab/
-
- TCFS improves on CFS, adding more integration with the file system, so
- that it's transparent to any users using the file system that it's
- encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/
-
- 4.8. X11, SVGA and display security.
-
- 4.8.1. X11
-
- It's important for you to secure your graphical display to prevent
- attackers from doing things like: grabbing your passwords as you type
- them without you knowing it, reading documents or information you are
- reading on your screen, or even using a hole to gain superuser access.
- Running remote X applications over a network also can be fraught with
- peril, allowing sniffers to see all your interaction with the remote
- system.
-
- X has a number of access control mechanisms. The simplest of them is
- host based. You can use xhost to specify what hosts are allowed access
- to your display. This is not very secure at all. If someone has access
- to your machine they can xhost + their machine and get in easily.
- Also, if you have to allow access from an untrusted machine, anyone
- there can compromise your display.
-
- When using xdm (x display manager) to login, you get a much better
- access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and
- stored in your .Xauthorty file. If you need to allow a remote machine
- access to your display, you can use the xauth command and the
- information in your .Xauthority file to provide only that connection
- access.
-
- You can also use ssh (see ssh, above) to allow secure X connections.
- This has the advantage of also being transparent to the end user, and
- means that no un-encrypted data flows across the network.
-
- Take a look at the Xsecurity man page for more information on X
- security. The safe bet is to use xdm to login to your console and then
- use ssh to go to remote sites you wish to run X programs off of.
-
- 4.8.2. SVGA
-
- SVGAlib programs are typically suid root in order to access all your
- linux machines video hardware. This makes them very dangerous. If they
- crash, you typically need to reboot your machine to get a usable
- console back. Make sure any SVGA programs you are running are
- authentic, and can at least be somewhat trusted. Even better, don't
- run them at all.
-
- 4.8.3. GGI (Generic Graphics Interface project)
-
- The linux GGI project is trying to solve several of the problems with
- video interfaces on linux. GGI will move a small piece of the video
- code into the linux kernel, and then control access to the video
- system. This means GGI will be able to restore your console at any
- time to a known good state. They will also allow a secure attention
- key, so you can be sure that there is no Trojan horse login program
- running on your console. http://synergy.caltech.edu/~ggi/
-
- 4.9. identd
-
- identd is a small program that typically runs out of your inetd. It
- keeps track of what user is running what tcp service, and then reports
- this to whoever requests it.
-
- Many people misunderstand the usefulness of identd, and so disable it
- or block all off site requests for it. identd is not there to help out
- remote sites. There is no way of knowing if the data you get from the
- remote identd is correct or not. There is no authentication in identd
- requests.
-
- Why would you want to run it then? Because it helps _you_ out, and is
- another data-point in tracking. If your identd is un compromised, then
- you know it's telling remote sites the user-name or uid of people
- using tcp services. If the admin at a remote site comes back to you
- and tells you user so and so was trying to hack into their site, you
- can easily take action against that user. If you are not running
- identd, you will have to look at lots and lots of logs, figure out who
- was on at the time, and in general take a lot more time to track down
- the user.
-
- The identd that ships with most distributions is more configurable
- than many people think. You can disable identd for specific users
- (they can make a .noident file), you can log all identd requests (I
- recommend it), you can even have identd return a uid instead of a user
- name or even NO-USER.
-
- 5. Network Security
-
- Network security is becoming more and more important as people spend
- more and more time connected. Compromising network security is often
- much easier than physical or local, and is much more common.
-
- There are a number of good tools to assist with network security, and
- more and more of them are shipping with linux distributions.
-
- 5.1. Packet Sniffers
-
- One of the most common ways intruders gain access to more systems on
- your network is by employing a packet sniffer on a already compromised
- host. This "sniffer" just listens on the Ethernet port for things like
- "Password" and "Login" and "su" in the packet stream and then logs the
- traffic after that. This way, attackers gain passwords for systems
- they are not even attempting to break into. Clear text passwords are
- very vulnerable to this attack.
-
- EXAMPLE: host A has been compromised. Attacker installs a sniffer.
- Sniffer picks up admin logging into host B from Host C. It gets the
- admins personal password as they login to B. Then, the admin does a
- 'su' to fix a problem. They now have the root password for Host B.
- Later the admin lets someone telnet from his account to host Z on
- another site. Now the attacker has a password/login on host Z.
-
- In this day and age, the attacker doesn't even need to compromise a
- system to do this, they could also bring a laptop or pc into a
- building and tap into your net.
-
- Using ssh or other encrypted password methods thwarts this attack.
- Things like APOP for pop accounts also prevents this attack. (Normal
- pop logins are very vulnerable to this, as is anything that sends
- clear text passwords over the wire.)
-
- 5.2. System services and tcp_wrappers
-
- As soon as you put your linux system on ANY network the first thing to
- look at is what services you need to offer. Services that you do not
- need to offer should be disabled so that you have one less thing to
- worry about and attackers have one less place to look for a hole.
-
- There are a number of ways to disable services under linux. You can
- look at your /etc/inetd.conf file and see what services are being
- offered by your inetd. Disable any that you do not need by commenting
- them out (# at the beginning of the line), and then sending your inetd
- process a SIGHUP.
-
- You can also remove (or comment out) services in your /etc/services
- file. This will mean that local clients will also be unable to find
- the service (ie, if you remove ftp, and try and ftp to a remote site
- from that machine it will fail with an unknown service message). It's
- usually not worth the trouble to remove services, since it provides no
- additional security. If a local person wanted to use ftp even tho you
- had commented it out, they would make their own client that use the
- common ftp port and would still work fine.
-
- If you know you are not going to use some particular package, you can
- also delete it entirely. rpm -e under the redhat distribution will
- erase an entire package. Under debian dpkg likely does the same thing.
-
- You should check your /etc/rc.d/rcN.d, where N is your systems run
- level and see if any of the servers started in that directory are not
- needed. Simply remove the unneeded script(s) and they will not be
- started on your next reboot. If you have BSD style rc files, you will
- want to check /etc/rc* for programs you don't need.
-
- Most linux distributions ship with tcp_wrappers "wrapping" all your
- tcp services. A tcp_wrapper (tcpd) is invoked from inetd instead of
- the real server. tcpd then checks the host that is requesting the
- service and either launches the program or denies access from that
- host. tcpd allows you to restrict access to your tcp services. You
- should make a /etc/hosts.allow and add in only those hosts that need
- to have access to your machines services. If you are a home dialup
- user, I would suggest you deny ALL. tcpd also logs failed attempts to
- access services, so this can give you an idea that you are under
- attack. If you add new services, you should always tcp wrapper them if
- they are tcp based.
-
- 5.3. SATAN , ISS, and other network scanners
-
- There are a number of different software packages out there that do
- port and service based scanning of machines or networks. SATAN and ISS
- are two of the more well known ones. This software connects to the
- target machine (or all the target machines on a network) on all the
- ports it can, and tries to determine what service is running there.
- Based on this information, you could find out the machine is
- vulnerable to a specific exploit on that server.
-
- SATAN (Security Administrators Tool for Analyzing Networks) is a port
- scanner with a web interface. It can be configured to do light,
- medium, or strong checks on a machine or a network of machines. It's a
- good idea to get SATAN and scan your machine or network, and fix the
- problems it finds. Make sure you get the copy of SATAN from sun-site
- or a reputable FTP or web site. There was a Trojan copy of SATAN that
- was distributed out on the net.
- http://www.trouble.org/~zen/satan/satan.html
-
- ISS (Internet Security Scanner) is another port based scanner. It is
- faster than Satan, and thus might be better for large networks.
- However, SATAN tends to provide more information.
-
- Detecting Port scans.
-
- There are some tools designed to alert you to probes by Satan and ISS
- and other scanning software, However liberal use of tcp_wrappers and
- making sure to look over your log files regularly, you should be able
- to notice such probes. Even on the lowest setting, Satan still leaves
- traces in the logs on a stock Redhat system.
-
- 5.4. pgp and public key cryptography
-
- pgp (pretty good privacy) is well supported on linux. versions 2.62
- and 5.0 are known to work well. For a good primer on pgp and how to
- use it, take a look a the pgp FAQ.
- http://www.pgp.com/service/export/faq/55faq.cgi
-
- 5.5. ssh and stelnet
-
- ssh (secure shell) and stelnet are programs that allow you to login to
- remote systems and have a encrypted connection.
-
- Ssh will prevent host spoofing attacks (It expects a specific key back
- from a host it's connected to before), it does compression and X11
- forwarding in addition to encrypting all your communications with the
- remote machines. This is very good to defeat packet sniffer attacks
- (The packet sniffer gets a bunch of encrypted packets). ssh is free
- for personal use, so I would recommend you install it and use it if
- you are at a personal site. http://www.cs.hut.fi/ssh/
-
- Stelnet is a secure telnet replacement that does encryption over a
- telnet connection.
-
- 5.6. sendmail, qmail and MTA's.
-
- One of the most important services you can provide is a mail server.
- Unfortunately, it is also one of the most vulnerable to attack, simply
- due to the number of tasks it must perform and the privileges it
- typically needs.
-
- If you are using sendmail it is very important to keep up on current
- versions. Sendmail has a long long history of security exploits.
- Always make sure you are running the most recent version.
- http://www.sendmail.org
-
- If you are tired of upgrading your version of sendmail every week, you
- might consider switching over to qmail. qmail was designed with
- security in mind from the ground up. It's fast and stable and secure.
- http://www.qmail.org
-
- 5.7. Denial of service attacks.
-
- A Denial of service attack is one where the attacker tries to make
- some resource too busy to answer legitimate requests, or to deny
- legitimate users access to your machine.
-
- Denial of service attacks have increased greatly in recent years. Some
- of the more popular and recent ones are listed below. Note that new
- ones show up all the time, so this is just a few examples. Read the
- linux security lists for more current information.
-
- SYN flooding. SYN flooding is a network denial of service attack. It
- takes advantage of a "loophole" in the way TCP connections are
- created. The newer linux kernels (2.0.30 and up) have several
- configurable options to prevent SYN flood attacks from denying people
- access to your machine or services. CONFIG_SYN_COOKIES and
- CONFIG_RST_COOKIES. Rebuild your kernel with these options to reduce
- your susceptibility to SYN flood attacks.
-
- Pentium "F00F" bug. It was recently discovered that a series of
- assembly codes send to a genuine Intel Pentium processor would lock
- the machine up totally. This affects every machine with a Pentium
- processor (not clones, not Pentium Pro or PII), no matter what
- operating system it's running. Linux kernel 2.0.32 and up contain a
- work around for this bug, preventing it from locking your machine. If
- you are running on a pentium, you should upgrade now!
-
- Ping flooding. Ping flooding is a simple brute force denial of service
- attack. Your attacker send a "flood" of ICMP packets to your machine.
- If they are doing this from a host with better bandwidth than yours,
- your machine will be unable to send anything on the network. A
- variation on this attack "smurfing" sends ICMP packets to a host with
- _your_ machines return IP, allowing them to flood you less detectably.
- If you are under a ping flood attack, use a tool like tcpdump to
- determine where the packets are coming from (or appear to be coming
- from), then contact your provider with this information. Ping floods
- can most easily be stopped at the router level.
-
- 5.8. NFS (Network File System) security.
-
- NFS is a very widely used file sharing protocol. It allows servers
- running nfsd and mountd to "export" entire filesystems to other
- machines with nfs filesystem support builtin to their kernels (or some
- other client support if they are non linux machines). Mountd keeps
- track of mounted filesystems in /etc/mtab, and can display them with
- 'showmount'.
-
- Many sites use NFS to serve home directories to users, so that no
- matter what machine in the cluster they login to, they will have all
- their home files.
-
- There is some small amount of "security" allowed in exporting
- filesystems. You can make your nfsd map the remote root user (uid=0)
- to the nobody user, denying them total access to the files exported.
- However, since individual users have access to their own (or at least
- the same uid) files, the remote superuser can login or su to their
- account and have total access to their files. This is only a small
- hindrance to an attacker that has access to mount your remote
- filesystems.
-
- If you must use NFS, make sure you export to only those machines that
- you really need to export only. Never export your entire root
- directory, export only directories you need to export.
-
- See the NFS HOWTO for more information on NFS: NFS HOWTO
-
- 5.9. NIS (Network Information service) (formerly YP).
-
- Network Information service (formerly YP) is a means of distributing
- information to a group of machines. The NIS master holds the
- information tables and converts them into NIS map files. These maps
- are then served over the network, allowing NIS client machines to get
- login, password, home directory and shell information (all the
- information in a standard /etc/passwd file). This allows users to
- change their password once and have it take affect on all the machines
- in the NIS domain.
-
- NIS is not at all secure. It was never meant to be. It was meant to be
- handy and usefull. Anyone that can guess the name of your NIS domain
- (anywhere on the net) can get a copy of your passwd file, and use
- crack and john the ripper against your users passwords. Also, it is
- possible to spoof NIS and do all sorts of nasty tricks. If you must
- use NIS, make sure you are aware of the dangers.
-
- There is a much more secure replacement for NIS, called NIS+. Check
- out the NIS HOWTO for more information:
- http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html
-
- 5.10. Firewalls
-
- Firewalls are a means of restricting what information is allowed into
- and out of your local network. Typically the firewall host is
- connected to the Internet and your local lan, and the only access from
- your lan to the Internet is through the firewall. This way the
- firewall can control what passes back and forth from the Internet and
- your lan.
-
- There are a number of types and methods of setting up firewalls. Linux
- machines make pretty good low cost firewalls. firewall code can be
- built right into 2.0 and higher kernels. The ipfwadm user space tool
- allows you to change what types of network traffic you allow on the
- fly. You can also log particular types of network traffic.
- Firewalls are a very usefull and important technique in securing your
- network. It is important to realize that you should never think that
- because you have a firewall, you don't need to secure the machines
- behind it. This is a fatal mistake. Check out the very good Firewall-
- HOWTO at your latest sun-site archive for more information on
- firewalls and linux. http://sunsite.unc.edu/mdw/HOWTO/Firewall-
- HOWTO.html
-
- 6. What to do during and after a breakin
-
- So you have followed some of the advice here (or elsewhere) and have
- detected a breakin? The first thing to do is to remain calm. Hasty
- actions can cause more harm than the attacker would have.
-
- 6.1. Security Compromise under way.
-
- Spotting a security compromise under way can be a tense undertaking.
- How you react can have large consequences.
-
- If the compromise you are seeing is a physical one, odds are you have
- spotted someone who has broken into your home, office or lab. You
- should notify your local authorities. In a lab setting you might have
- spotted someone trying to open a case or reboot a machine. Depending
- on your authority and procedures, you might ask them to stop, or
- contact your local security people.
-
- If you have detected a local user trying to compromise your security,
- the first thing to do is confirm they are in fact who you think they
- are. Check the site they are logging in from. Is it the site they are
- normally in from? no? Then use a non electronic means of getting in
- touch. For instance call them on the phone or walk over to their
- office/house and talk to them. If they agree that they are on, you can
- ask them to explain what they were doing or tell them to cease doing
- it. If they are not on, and have no idea what you are talking about,
- odds are this incident requires further investigation. Look into such
- incidents , and have lots of information before making any
- accusations.
-
- If you have detected a network compromise, the first thing to do (if
- you are able) is to disconnect your network. If they are connected via
- modem, unplug the modem cable, if they are connected via ethernet,
- unplug the ethernet cable. This will prevent them from doing any
- further damage, and they will probably see it as a network problem
- rather than detection.
-
- If you are unable to disconnect the network (if you have a busy site,
- or you do not have physical control of your machines), the next best
- step is to use something like tcp_wrappers or ipfwadm to deny access
- from the intruders site.
-
- If you can't deny all people from the same site as the intruder,
- locking the users account will have to do. Note that locking an
- account is not an easy thing. You have to keep in mind .rhosts files,
- FTP access, and a host of backdoors).
-
- After you have done one of the above (disconnected network, denied
- access from their site, and/or disabled their account), you need to
- kill all their user processes and log them off.
-
- You should monitor your site well for the next few minutes, as the
- attacker will try and get back in. Perhaps using a different account,
- and/or from a different network address.
-
- 6.2. Security Compromise has already happened.
-
- So you have either detected a compromise that has already happened or
- you have detected it and locked (hopefully) the offending attacker out
- of your system. Now what?
-
- 6.2.1. Closing the Hole
-
- If you are able to determine what means the attacker used to get into
- your system, you should try and close that hole. For instance, perhaps
- you see several FTP entries just before the user logged in. Disable
- the FTP service and check and see if there is an updated version or
- any of the lists know of a fix.
-
- Check all your log files, and make a visit to your security lists and
- pages and see if there are any new common exploits you can fix.
-
- If you don't lock the attacker out, they will likely be back. Not just
- back on your machine, but back somewhere on your lan. If they were
- running a packet sniffer, odds are good they have access to other
- local machines.
-
- 6.2.2. Assessing the Damage
-
- The first thing is to assess the damage. What has been compromised?
- If you are running an Integrity Checker like Tripwire you can make a
- tripwire run and it should tell you. If not, you will have to look
- around at all your important data.
-
- Since linux systems are getting easier and easier to install, you
- might consider saving off your config files and then wiping your
- disk(s) and reinstalling, then restoring your user files from backups
- and your config files. This will insure that you have a new clean
- system.
-
- 6.2.3. Backups, Backups, Backups!
-
- Having regular backups is a godsend for security matters. If your
- system is compromised, you can restore the data you need from backups.
- Of course some data is valuable to the attacker to, and they will not
- only destroy it, they will steal it and have their own copies, but at
- least you will still have the data.
-
- You should check several backups back into the past before restoring a
- file that has been tampered with. The intruder could have compromised
- your files long ago, and you could have made many successful backups
- of the compromised file!!!
-
- Of course, there are also a raft of security concerns with backups.
- Make sure you are storing them in a secure place. Know who has access
- to them. (If an attacker can get your backups, they can have access to
- all your data without you ever knowing it.)
-
- 6.2.4. Tracking down the intruder.
-
- Ok, you have locked the intruder out, and recovered your system, but
- you're not quite done yet. While it is unlikely that most intruders
- will ever be caught, you should report the attack.
-
- You should report the attack to the admin contact at the site where
- the attacker attacked your system. You can look up this contact with
- "whois" or the internic database. You might send them an email with
- all applicable log entries and dates and times. If you spotted
- anything else distinctive about your intruder, you might mention that
- too. After sending the email, you should (if you are so inclined)
- follow up with a phone call. If that admin in turn spots your
- attacker, they might be able to talk to the admin of the site where
- they are coming from and so on.
-
- Good hackers often use many intermediate systems. Some (or many) of
- which may not even know they have been compromised. Trying to track a
- cracker back to their home system can be difficult. Being polite to
- the admins you talk to can go a long way to getting help from them.
-
- You should also notify any security organizations you are a part of
- (cert or similar).
-
- 7. Security sources
-
- There are a LOT of good sites out there for unix security in general
- and linux security specifically. It's very important to subscribe to
- one (or more) of the security mailing lists and keep current on
- security fixes. Most of these lists are very low volume, and very
- informative.
-
- 7.1. FTP sites
-
- CERT is the Computer Emergency Response Team. They often send out
- alerts of current attacks and fixes. cert.org
-
- Replay has archives of many security programs. Since they are outside
- the US, they don't need to obey any silly US crypto restrictions.
- replay.com
-
- Matt Blaze is the author of CFS and a great security advocate. Matt
- Blaze's stuff
-
- Sorosis is the home of the linux PAM site. They have lots of modules
- and information on PAM. Linux PAM ftp site
-
- tue.nl is a great security ftp site in the Netherlands.
- ftp.win.tue.nl
-
- 7.2. The Hacker FAQ is a FAQ about hackers: The Hacker FAQ web sites
-
- The COAST archive has a large number of unix security programs and
- information: COAST
-
- Rootshell.com is a great site for seeing what exploits are currently
- being used by crackers: rootshell.com exploits
-
- BUGTRAQ puts out advisories on security issues: BUGTRAQ archives
-
- CERT, the Computer Emergency Response Team, puts out advisories on
- common attacks on unix platforms: CERT home
-
- Dan Farmer is the author of SATAN and many other security tools, his
- home site has some interesting security survey information as well as
- security tools: Dan Farmers trouble.org
-
- The linux security WWW is a good site for linux security information:
- Linux Security WWW
-
- Reptile has lots of good linux security information on his site:
- Reptiles Linux Security Page
-
- Infilsec has a vulnerability engine that can tell you what
- vunerabilities affect a specific platform: Infilsec vunerability
- engine
-
- CIAC sends out periodic security bulitins on common exploits: CIAC
- bulitins
-
- 7.3. mailing lists
-
- Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org
- containing the message body subscribe bugtraq. (see links above for
- archives).
-
- CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not
- subject) of the message put (either or both): subscribe ciac-bulletin
-
- 7.4. Books - printed reading material.
-
- There are a number of good security books out there. This section
- lists a few of them. In addition to the security specify books,
- security is covered in a number of other books on system
- administration.
-
- Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky
-
- 1st Edition September 1995
-
- ISBN: 1-56592-124-0
-
- Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel &
- Gene Spafford
-
- 2nd Edition April 1996
-
- ISBN: 1-56592-148-8
-
- Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr.
-
- 1st Edition July 1991
-
- ISBN: 0-937175-71-4
-
- Linux Network Administrator's Guide By Olaf Kirch
-
- 1st Edition January 1995
-
- ISBN: 1-56592-087-2
-
- PGP: Pretty Good Privacy By Simson Garfinkel
-
- 1st Edition December 1994
-
- ISBN: 1-56592-098-8
-
- Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &
- William VonStorch (Consulting Editor Eugene H. Spafford)
-
- 1st Edition August 1995
-
- ISBN: 1-56592-086-4
-
- 8. Conclusion
-
- By subscribing to the security alert mailing lists, and keeping
- current, you can do a lot towards securing your machine. If you pay
- attention to your log files and run something like tripwire regularly,
- you can do even more.
-
- A reasonable level of computer security is not difficult to maintain
- on a home machine. More effort is required on business machines, but
- linux can indeed be a secure platform. Due to the nature of linux
- development, security fixes often come out much faster than they do on
- commercial operating systems, making linux an ideal platform when
- security is a requirement.
-
- 9. Thanks to
-
- Information here is collected from many sources. Thanks to the
- following that either indirectly or directly have contributed:
-
- Rob Riggs <rob@DevilsThumb.com>
- S. Coffin <scoffin@netcom.com>
- Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu>
- Roelof Osinga <roelof@eboa.com>
- Kyle Hasselbacher <kyle@carefree.quux.soltec.net>
- "David S. Jackson" <dsj@dsj.net>
-
-